\section{Agent Feruthol}
This chapter describes the implementation of the negotiating agent “Feruthol” (\textbf{Fe}lix, \textbf{Ru}ben, \textbf{Th}omas, \textbf{Ol}iver). The applied data structures and algorithms are explained in detail and discussed.

\subsection{Programming language and environment}
The agent has been implemented in the programming language Java. Since Genius itself is programmed in Java and provides a complete framework for developing negotiating agents, this is the most convenient choice.
In order to run and debug the agent, the integrated development environment NetBeans IDE has been used. The jar-file “negosimulator.jar” of Genius \cite{genius} has been integrated in the NetBeans project (see figure \ref{fig:packages}) to serve as a library. For debugging purposes, the main-method of the jar-file is called, so the debugging process can be controlled by the NetBeans functions and the behavior of the implemented agent can be monitored.
\begin{figure}[h]\centering
\begin{minipage}{.5\textwidth}%
\centering\leavevmode
\includegraphics[width=\textwidth]{./Pictures/packages.png}
\caption{NetBeans project structure}\label{fig:packages}

\end{minipage}
\end{figure}
\subsection{Negotiation strategy}
The negotiation strategy of Agent Feruthol is based on the Adaptive Bilateral Negotiating Strategy over Multiple Items (ABiNeS, as described in chapter \ref{abines}).
This negotiation model roughly consists of four main components: the acceptance-threshold component, the next-bid component, the acceptance-condition component and the termination-condition component.
Each one of these components is implemented in an individual method within the AgenFeruthol-class.
These components are called from the chooseAction()-method, which is provided by the Agent-class of the Genius framework and which request the next action by Agent Feruthol.
\subsection{Negotiation history}
The negotiation history stores every incoming offer by the negotiating partner. It is implemented as a simple Stack of Bid-Objects, which allows an easy access to the elements. The negotiation history plays an important role throughout the entire algorithm because it severely influences the decision process of Agent Feruthol.
\subsection{Acceptance threshold}
The first value that is needed when choosing the next action for the agent is the acceptance threshold. This value determines the concession degree of the agent, thus the range of acceptable negotiation outcomes. It is the value with the greatest influence on the entire behavior of the agent.

\subsubsection{Fine-tuning of the constants}
\label{finetuning}
The value of the threshold strongly depends on the value of the non-exploitation point (variable name "lambda") as well as a number of constants which are solidly defined at the top of the AgentFeruthol-class.
Thus the fine-tuning of these values is an important step of the development process.
The following table shows the constants that are related to the determination of the threshold, their fixed value and an explanation for this chosen value, justified by the resulting influence on the agent’s behavior.

\begin{table}[htb]
\centering
\begin{tabularx}{\textwidth}{|l|l|X|}
\hline
\textbf{Constant} & \textbf{Value} & \textbf{Explanation and consequence}\\
\hline
ALPHA & 1 & This value makes the acceptance threshold approach the smallest acceptable value before reaching lambda in a linear way.\\
\hline
LAMBDA0 & 0.2 & This is the initial value of lambda.
It is set very low because if lambda is initially very high, the threshold is not going to go very low and the agent is not concessive at all.
After testing the behavior against a number of partners we came to the conclusion that the agent should be more concessive to come to more agreements. \\
\hline
BETA & 10 & BETA is only important for the initial value of lambda.
It is set very high to initialize lambda with a value that is very close to LAMBDA0, so lambda has a greater range to increase. \\
\hline
WEIGHT & 0.001 & This value is set very low, causing lambda to increase rather slowly.
If lambda increases too quickly, the threshold never reaches a concessive value, but always stays very close to 1, making it impossible to find an agreement. \\
\hline
GAMMA & 1 & No particular behavior implemented here, since lambda already increases slowly because of WEIGHT. \\
\hline
\end{tabularx}
\end{table}
\FloatBarrier

\subsubsection{Concessive degree sigma}

The value of lambda also depends on the concessive degree of the negotiating partner.
This value is simply computed by comparing the last 10 bids of the partner and calculating the ratio of distinguishable bids of those 10 bids.
So the more different offers the partner has made in the last 10 bids, the more concessive he is considered.

\subsection{Selecting the next bid}

After determining the acceptance threshold, Agent Feruthol is selecting the next Bid, which will be proposed if he decides to make a new offer.
In order to do so, the agent first creates a list of candidate bids.
All bids with a utility greater than or equal to the previously determined threshold are considered candidates.
Another list is created, which contains the frequency of every issue-value pair that has been proposed by the negotiating partner.
These frequencies are stored in an individually developed frequency map (FrequencyMap.class).
Every time Agent Feruthol receives an offer, the proposed value for every issue is compared with the already stored values.
If an issue-value pair already exists in the frequency map, the frequency is increased. Otherwise this isse-value pair is added to the map with a frequency of 1.
For example, assume that the negotiating partner has offered the following bids:

\begin{itemize}
\item Computer: Dell   -   Harddrive: 30 GB   -   Screensize: 24 inch
\item Computer: Acer   -   Harddrive: 20 GB   -   Screensize: 26 inch
\end{itemize}

\noindent Then the frequency map would have the following entries:

\begin{table}[htb]
\centering
\begin{tabular}{|l|r|r|}
\hline
Issue & Value & Frequency\\
\hline
Computer & “Dell” & 1 \\
Harddrive & 30 & 1 \\
Screensize & 24 & 1 \\
\hline
Computer & “Acer” & 1 \\
Harddrive & 20 & 1 \\
Screensize & 26 & 1 \\
\hline
\end{tabular}
\end{table}

\noindent Now assume the partner proposes the following bid:

\begin{itemize}
\item Computer: Acer   -   Harddrive: 30 GB   -   Screensize: 28 inch
\end{itemize}

\noindent Then the frequency map would be updated as follows:

\begin{table}[htb]
\centering
\begin{tabular}{|l|r|r|}
\hline
Issue & Value & Frequency\\
\hline
Computer & “Dell” & 1 \\
Harddrive & 30 & 2 \\
Screensize & 24 & 1 \\
\hline
Computer & “Acer” & 2 \\
Harddrive & 20 & 1 \\
Screensize & 26 & 1 \\
Screensize & 28 & 1 \\
\hline
\end{tabular}
\end{table}

\noindent After the bid candidates have been determined, the frequency for every one of these bids is obtained from the frequency map by summing up the frequencies of the contained issue-value pair.
So in this case, all the bids that contain the issue-value pairs Harddrive/30 and Computer/”Acer” would have the highest frequency.
These frequencies are used to approximate the preferences of the negotiating partner to act accordingly.

In the implementation a discounting factor of the frequencies is taken into account as well, which is not considered for the sake of the simplicity of this example.
 Also, the isse-value pairs are implemented in an individual class (IssueValue.class) as well, which defines the comparison between issue value pairs.

After obtaining the frequencies for the candidates, they are sorted according to the frequency, starting with the highest.
The constant ETA (= 0.8) then determines that with a probability of 80\% the candidate bid with the highest frequency (first of the list after sorting) is chosen and with a probability of 20\% a random candidate is chosen as the next bid.
So Agent Feruthol is rather willing to exploit his gained knowledge about the partner.

\subsection{Acceptance and termination condition}

The condition for acceptance and for termination are both implemented very simplistically, only using if-statements according to the description in chapter \ref{Offeracceptance}.
The communication between the acceptance condition and the next-bid component is handled by a global Boolean flag.
If the utility of the best outcome of the bid history is greater than the threshold and greater than the utility of the last offer, the flag is set to true.
If the next bid component then finds this true value, it immediately returns the best outcome of the bid history as the next bid.